feat(platform): introduce protocol version 13#4143
Conversation
Functionally identical to v12 at introduction — same component version structs throughout. v13 exists as the activation gate for a follow-up consensus change: recording shielded-spend transparent credits (Unshield / shield surplus / identity-create fallback) into the recent-address-balance-changes tree (#4142), so mixed-version validators agree until the voted switchover instead of forking on the first such transition. Registration follows the established pattern: v13 module, the PLATFORM_VERSIONS array, LATEST_PLATFORM_VERSION → PLATFORM_V13 (DESIRED_PLATFORM_VERSION follows by alias). Deliberately unchanged: the SDK per-network minimum-version floors (testnet still runs v12 — the floor ratchets when the network actually reports 13), feature_initial_protocol_versions markers (v13 activates nothing at introduction), and the migration dispatch (no new GroveDB structures; a v12→v13 upgrade is correctly a no-op). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
✅ Final review complete — no blockers (commit c281488) |
QuantumExplorer
changed the title
|
Warning Review limit reached
Next review available in: 1 minute Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (3)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
thepastaclaw
left a comment
thepastaclaw
left a comment
There was a problem hiding this comment.
Final validation — Codex + Sonnet
This PR mechanically registers protocol version 13 as an intentional byte-for-byte clone of v12, correctly wiring LATEST_PLATFORM_VERSION, PLATFORM_VERSIONS, and DESIRED_PLATFORM_VERSION, with v13 serving as an activation gate for a planned follow-up consensus change. The only in-scope issue is that advancing latest() to v13 causes three existing tests explicitly named for v11-to-v12 migration behavior to silently bind their platform_version_12 variable to PlatformVersion::latest() (now v13) instead of an explicit v12 lookup, which is harmless today but will quietly stop protecting the v12 boundary once v13 diverges as planned.
Review provenance
- Codex reviewers:
gpt-5.6-sol— general (failed),gpt-5.6-sol— rust-quality (failed),gpt-5.6-sol— general (failed),gpt-5.6-sol— rust-quality (failed),gpt-5.6-sol— general (failed),gpt-5.6-sol— rust-quality (failed),gpt-5.6-sol— general (completed),gpt-5.6-sol— rust-quality (completed) - Verifier:
claude-sonnet-5— verifier - Sonnet reviewers:
claude-sonnet-5— general (failed),claude-sonnet-5— rust-quality (failed),claude-sonnet-5— general (failed),claude-sonnet-5— general (failed),claude-sonnet-5— rust-quality (completed),claude-sonnet-5— general (completed)
🟡 1 suggestion(s)
1 additional finding(s) omitted (not in diff).
🤖 Prompt for all review comments with AI agents
These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.
In `packages/rs-drive-abci/src/execution/platform_events/protocol_upgrade/perform_events_on_first_block_of_protocol_change/v0/mod.rs`:
- [SUGGESTION] packages/rs-drive-abci/src/execution/platform_events/protocol_upgrade/perform_events_on_first_block_of_protocol_change/v0/mod.rs:1084: Pin v12 migration tests to protocol version 12 explicitly
Three tests explicitly named and structured to verify v11-to-v12 migration behavior (at lines 1084, 1376, and 1600) bind `platform_version_12` to `PlatformVersion::latest()` rather than an explicit version lookup. This PR advances `latest()` from v12 to v13, so these tests now silently exercise v13 dispatch instead of v12. Since v13 is deliberately identical to v12 today, the tests still pass, but this PR establishes v13 as the gate for a planned follow-up divergence. Once that lands, these tests will stop protecting the v12 migration boundary they claim to cover. A sibling test at line 1893 already uses `PlatformVersion::get(12).expect("expected v12")`. Pin all three to version 12 explicitly.
2 participants
What
Introduces protocol version 13, functionally identical to v12 — same component version structs throughout, no behavior change at introduction.
Why
Foundation for rolling-upgrade safety on #4142: recording shielded-spend transparent credits (Unshield / shield surplus / identity-create fallback) into the recent-address-balance-changes tree changes the committed state root, so it must not activate until validators agree — #4142 will be reworked to gate the new recording on v13, activated by the normal masternode version voting instead of requiring a lockstep deploy.
Changes
v13.rs: exact clone of v12 (verified by diff: only the constant, the struct name, and the doc comment differ). Per repo convention, v12's inline "changed:" delta comments are dropped — they document deltas introduced at v12.mod.rs,protocol_version.rsimports,PLATFORM_VERSIONSarray,LATEST_PLATFORM_VERSION → &PLATFORM_V13(DESIRED_PLATFORM_VERSIONfollows by alias — drive-abci now advertises 13 to Tenderdash).Deliberately unchanged (each checked individually)
min_protocol_version: testnet/devnet/regtest = 12, mainnet = 11) — these are the currently running floors, not "latest"; they ratchet automatically when a network actually reports 13.feature_initial_protocol_versions— activation markers name the version where a feature turned on; v13 activates nothing at introduction (the fix(drive-abci): record unshield and shield-surplus credits in recent address balance changes #4142 follow-up adds its marker).perform_events_on_first_block_of_protocol_change) — v13 sharesDRIVE_VERSION_V7, no new GroveDB structures, so a v12→v13 upgrade is correctly a no-op fallthrough.PlatformVersion::get(12)/PROTOCOL_VERSION_12test and doc references to v12-activation-specific behavior.Verification
cargo fmt --checkclean;cargo checkon platform-version, dpp, drive-abci, dash-sdk cleancargo test -p platform-version→ 7 passed (incl. the shielded-pool v12 gating tests)cargo test -p drive-abci --lib protocol_upgrade→ 42 passed (transition chains, same-version no-op, v12 tree creation)cargo test -p dppstate-transition range assertions (92) + validation-result (61) green — the..=LATEST_VERSIONranges follow to 13cargo test -p dash-sdkversion floor/ratchet/pin tests → 55 passed🤖 Generated with Claude Code